A security, or cryptographic, protocol is an abstract or concrete protocol that performs a security-related function and applies cryptographic methods. Cryptographic protocols are widely used for secure application-level data transport. A cryptographic protocol usually incorporates at least some of these aspects: key agreement or establishment; entity authentication; symmetric encryption and message authentication material construction; secured application-level data transport; and non-repudiation methods.
A cryptographic protocol running over an unreliable transport mechanism requires means to synchronize the transmitter and receiver, for example, due to packet loss or packet reordering. At the lowest level, a receiver must be able to correctly assemble data packets into “intelligible” data; e.g., it must know if a data packet is missing so that it can request retransmission. Synchronization is typically accomplished by adding a sequence number to each pocket or by using an already existing sequence number. Such sequence numbers are then input to a cryptographic algorithm, together with the proper key, and synchronization is obtained on a per-packet basis. The latter approach is preferred, however, since it does not increase the amount of data and, thus, the necessary bandwidth.
Due to the properties of cryptographic transforms, the same sequence number should never be used twice with the same key. Conventional built-in counters, however, are typically only 16 bits and, thus, in high speed communications, a 16-bit sequence number space may “wrap” within a matter of seconds, leading to inefficiency due to necessary frequent re-keying. For example, with a 16-bit sequence number, every 216 packet will contain identical sequence numbers, and thus a receiver is unable to distinguish such packets.
To get around this problem, a roll-over counter (“ROC”) can be used to define an “extended” sequence number. For a 16-bit sequence number (sequence_number) and extended sequence number (EXTENDED_SEQ) could be equal to sequence_number+ROC*216. In such systems, the ROC should be updated on the transmitter and receiver sides whenever sequence_number “wraps” modulo 216. The ROC value, however, is typically not carried in the packets, but is implicitly maintained by the transmitter and receiver. It can be shown, however, that as long as packet re-order/loss is not more than 215, it is possible to maintain synchronization by estimating the ROC value based on heuristic methods; see, for example the Appendix of Internet Engineering Task Force (IETF) Request for Comments (RFC) 3711, “Secure Real-time Transport Protocol” (“SRTP”).
In some applications where users may join or leave an ongoing session (e.g., 3GPP Multi-cast and broadcast services (MBMS); where SRTP is to be used), however, the “extended” mechanism is not sufficient due to the fact that each user must be given the current ROC value and it is not trivial how to accurately transfer the information to the users. SRTP currently does not provide a mechanism to provide the ROC value using inband signaling. It is possible, however, to signal the value out-of-band using a key management protocol (e.g., Multimedia Internet KEYing (“MIKEY”), IETF RFC3830). The problem with this approach is that key management is typically performed by a separate process and it is not unlikely that the key management is performed long before a user decides to join a session. In this case, the value of ROC that was used when key management was performed will not be valid when a user joins a session.
Even though key management is performed more or less in synchronization with SRTP stream processing, it is possible that the ROC value will be incorrect due to the way SRTP estimates the extended sequence number. For example, assume that the media (SRTP) sequence number has just wrapped around (e.g., is equal to 0x0000) and that the key management reads the ROC value at this point in time. Next, the ROC value is transported to the user (receiver) and the user reads the ROC value and stores it for reference. Since it is possible that packets are re-ordered on the path between the media server and the user, the first media (SRTP) packet the user receives could be a delayed packet which happens to have, for example, a sequence number equal to 0xFFFF. In this situation, SRTP may process this (delayed) packet with a ROC value that is one too high. Also, the next SRTP packet received is likely to have a sequence number equal to 0x0000. In this situation, SRTP would guess, or estimate, that the sequence number has wrapped around and, thus, would increase its ROC value by one. This would cause loss of synchronization. Under conditions of heavy packet loss, or if the user leaves a session and rejoins after such a long period of time that the ROC has wrapped around at least one time, the problem re-appears.
Accordingly, there is a need in the art for methods for secure and bandwidth efficient cryptographic synchronization. Preferably, such methods should make efficient use of bandwidth and protect against unauthorized manipulation.